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TRANSPARENT ACCESS AUTHENTICATION IN GPRS CORE NETWORKS 


The present invention relates to a method and system for' 
transparent access authentication in 2G and 2.5G Mobile 
Access Networks. This includes communication networks of the 
GSM- , GPRS- and UMTS-standard well known to. skilled persons. 

In standardisation of Universal Mobile Telecommunication 
System (UMTS Rel.5) comprehensive means are foreseen to 
perform authentication on the application layer with no need 
tp interwork with the underlying radio and transport ■ 
networks. The mechanisms are* based on- the assumption that a 

* 

specific environment is prepared ..for deployment of IP 
Multimedia Subsystem (IMS ) services. It includes • the use of 
IMS SIM (ISIM) application, which in turn requires 
Rel . 99UICC V.s in the connected end devices to handle the 
authentication and key agreement (AKA) . 

•In case of deployment of IMS and IMS based services in a 
network environment which is characterised by the use of SIM 
cards, the standardised authentication mechanism will not be 
applicable . 

* 

It is the object of the invention to provide method and 
system for transparent access authentication which allow it 
to run authentication transparently to the end device , 
without • requiring proprietary extensions and functions on 
network or client side. 

This object is achieved by providing a method and .system 
as described in the independent claims. 
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Other features which are considered to be characteristic 
for the invention are set forth in the dependent claims. 

The present invention describes a. method for application 
layer authentication of subscribers, connected to the 
authenticating network domain by a 2G or 2.5G General Packet 

■ 

Radio Service (GPRS) core network or a 3G UMTS network. The 

authentication will be based on data which is assembled by 

the network layer during establishment of a PDP context in 

GPRS networks. This information is secured by standard SIM 

* 

card application. As the same mechanisms are used for 
authentication in 3G networks, the further described 
mechanism is also applicable there. No standard would be 
touched in any way while using a 2G or 2 . 5G access network> 

■ • 

because no authentication on- application layer is foreseen in 
the" standard. For UMTS Rel . 5 standards and following, the 
standard foresees specific methods. The use of the further 
described method, would be possible, although the standardised 

« * * i « ■ -w 

• « * * s 

authentication mechanism needs to be "switched off. Switching 
off the standardised authentication mechanism could be 

* 

interpreted as standard sensitive, but subsequent use of the 
further described mechanism would be standard compliant * 
again . 

Further, a migration path to UMTS Rel. 5 standardised, 
authentication and the concept for parallel us.e of both 
mechanisms is described. 

» 

The invention will now be described in further detail with 
reference .to the drawings. 

^ » 

4 

Figure 1 depicts the general architecture of the system for 
carrying out the invention; 
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Figure 2 depicts an embodiment of the invention with 
migration to IMS compliant architecture. 

■ 

» 

With reference to Figure 1, during PDP context establishment 
the Serving GPRS Support Node (SGSN) is authenticating the 
subscriber using the A3/A8 algorithm based on the end devices 
SIM card in case of GSM and 2 . 5G GPRS and EDGE access 
network. 

The Gateway GPRS Support Node 1 (GGSN) . receives a context 
creation request and queries a Radius (Registration) server 2 
(Remote Authentif ication Dial-In User Service) to get an IP 
address m assigned for the particular PDP context. Within the 

■ 

context the Radius server 2 receives the. MSISDN and/or the 
IMSI of the subscriber. 1 So in. the session database 3 of the 

« 

Radius server 2 there is stored for each PDP context a pair 
of IP address and IMSI/MSISDN. Based on the tunnel endpoint 
ID (TEID) the GGSN 1 filters all. packets running through the 
PDP context ■ once established, for the correct I P_ source 
address. This means the GGSN 1 checks matching TEID/IP 
20 address pairs, thus preventing falsification of source 

4 

addresses and so called "IP spoofing" for the complete 
lifecycle of the PDP context. The TEID unambiguously 

identifies a tunnel endpoint in the receiving GTP-U (GPRS 

■ 

Tunnelling Protocol - User) or GTP-C (GPRS Tunnelling 

25 Protocol - Control) protocol entity. The receiving side of a 

* « 

GTP tunnel locally assigns the TEID value for the 
transmitting side to use. The TEID values are exchanged 
between tunnel endpoints using GTP-C messages (or RANAP 

(Radio Access Network Application Part) in the UTRAN (UMTS 

. . . • 

30 terrestrial , Radio -Access Network 

In the application domain a subscriber database. 4 exists that 
stores all PublDs the subscriber is using in the domain, 
referring it' to his PrivID, which is unique in the respective 
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* - 

* 

application .domain. The PrivID is correlated with an MSISDN 
and/or IMSI . 

* 

In the request the user gives his PrivID for registration. 
Upon receiving the registration request, the registration 

* 

5 proxy 5 queries the subscriber database 4 containing the 

subscribers IDs (both public and private) together with the 
MSISDN/IMSI. This data is stored in a table on the proxy 
server. platform. 

Subsequently the pxoxy server 5 queries the session database 
10 3 of the Radius- server 2 in order to get the assigned IP 
address of that session and the IMSI/MSISDN already 
authenticated by the network's Home Location. Register (HLR) . 

* ■ 

The authentication of the HLR guarantees further that the IP 

• « 

address can be considered to be authenticated as well-. Also 
15 this information is stored in the table on the- proxy server 
.platform. 

Now the proxy server 5 starts the authentication procedure 

■ 

according to the invention. 

20 

First, the proxy server 5 checks IMSI/MSISDN from Radius 
server 2 database 3 and application domain database 4 for 
match. If the pairs are not' matching, the subscriber has 
tried to' register with an incorrect PrivID, which is not 
25 correlated with his IMSI/MSISDN, if the pairs are matching 
the next step is performed. 

■ 

Second step is checking the subscribers IP address in the IP 
network layer, meaning in the IP packet overhead field for 
30 source address for match with the IP address assigned by the 
Radius server 3. As the IP address was assigned to an 
IMSi/MSISDN-authenticated session, also the IP address can be 
considered as authenticated. 
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5 

If the pairs a : re not matching, the subscriber used an 
incorrect IP address, if the pairs are' matching the 
subsequent step is performed. 

The proxy server 5 parses the application layer for IP 

addresses given in the headers of e.g. SIP registration 

message, SDP message bodies, etc and checks for match with 

the IP address in, which was already checked for match with 

the IP address assigned by the Radius server 2. If the pairs 

are not matching the subscriber used incorrect signalling 

information, e. g. response addresses., etc. If the pairs are 

* * ■ . 

matching, the session' setup can be considered as 

■ » 

authenticated. 

• • 

» 

In .all subsequent messages arriving at the proxy server 5, it 
checks for match of IP" address in the IP packet overhead 

field for source address with that in- the application layer 

* 

protocol header- fields and verifier the matching- pairs- 

.. .... 

•against the IP address assigned by 'the Radius server 2. 
If PublDs are used, in the following session, the PublDs are ' 
checked against the PrivID which was stored in a table on the 
proxy server platform after querying the application domains 
database 4 . 

* ■ * i 

The described f unqtionality gives the network operator the 

• . 

opportunity to run authentication transparently to the end' 

... • • 

■ • 

device, without requiring proprietary extensions and 
functions on network or client side. In case of SIP based 
signalling, the migration- to fully standard compliant UMTS 
Rel;5 mechanisms and a strategy for parallel operation is 
necessary, this will be described now. 
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As the IMS domain as standardised . for UMTS Rel. 5. will include- 

* 

* 4 

its own authentication mechanism, it is necessary to support 
a scenario where the subscribers are migrating to ISIM 
enabled end devices. To exploit the benefits of the 
standardised authentication mechanism, both mechanisms have 
to be supported in parallel. 

This is done by an additional function that checks each 
incoming signalling message, first for .the protocol, if itis 
any other protocol than SIP, the session is routed to the 

* 

proxy server 5 . 

With reference to Figure 2, the. same routing decision is taken 
if the message is based on SIP, but the client does not 
support standardised UMTS Rel . 5 authentication . If the client. 

• * ■ 

. does support standardised authentication method, e.g. is ISIM 
enabled, the message is routed to- the standard compliant 
Proxy Call State Control Function (P-CSCF) . First trigger for 
routing decisions' is the protocol type, as described above. 
Further triggers could be the key exchange mechanism used for 
s.etting up the secured connection between UE and P-CSCF ( if 
the end device is starting key agreement, it can be 
considered as standard compliant and the request is routed to 

• • * • 

the P-CSCF), or other elements included in the UMTS Rel .5 . 

* * 

header as well as any private extension, which is, however, 
. possible- but not ■ necessary . If trigger points * .available in 
signalling should be insufficient, also database lookups can 
be used to base routing decisions on. 

* 

4 

. The authentication procedure is as follows 

First , a decision is required by which node P-CSCF 6 or proxy 
" server 5 the register shall be routed 
For this, a routing module 7 is provided which will be the 
standard entry point for all messages. The routing module 7 
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decides by evaluation of PrivID which node will handle the 
message. The. routing module 7 refers to subdomains (e.g. 
user@gprs.tmo.de and user@tmo.umts.de) within the domain part 
of the Network Access Identifier (NAI) , see 3GPP 
specification 23.228. This requires that NAIs for 3G 

r 

* 

subscribers have to provide subdomains. 

The routing module 7 shall set a routing entry, by using only 
the PrivID, subsequent messages shall be identified by the IP 
source address listed in the routing table. 
The routing module 7 identifies .the responsible proxy 
function, i.e. proxy server 5 or P-CS.CF €, by evaluating the 
PrivID CURIs subdomains) This rises the request towards 

■ 

IMSI/MSISDN land URIs to be chosen according to this 
functionality . 

In ease other protocols shall be . used beside SIP, such as 

■ 

e.g. SMTP, HTTP, SOAP (.NET), etc, the proxy server 5 must be 
extended, and authenticate the subscribers by use of the IP 
address, subsequently resolving the IMSI/MSISDN and matching 
of the- particular identifier of the protocol, which is stored 
in the subscriber profile of the subscriber database 4 . This 
requires the population of the subscriber profile with the 
required data elements and extension of the routing module to 
enable protocol, dependent routing. 

In case . separate access networks are used-, the application 
platform' has to know which type of access* network is used to 
adapt service delivery accordingly. This requires that a 

» 

change request has to be stated against the SGSN to enable it 

* 

to send the .access type to the GGSN which includes it in the 

* 

. radius request, so the access network type will be available 
in the session database 3. This enables all applications to 
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request the access network type and use it, e.g. 'for Qualit.y 
of Service (QoS) means. * 
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Abbreviations 



2.5G. 

second and half generation (e. g. GPRS, EDGE) 

* 

5 

2G 

second generation (e. g. GSM) 

• 

3G 

third generation (e. g. UMTS) 


AKA 

authentication and key agreement 


cc 

Circuit Switched 


IMS 

IP multimedia subsystem 

i 

10 

IMSI' 

* - 

International Mobile Subscriber Identity 

* 

I SIM 

IMS" SIM 


* 

MS ISDN . 

• * 

Mobile Station ISDN Number- 


NAI 

* a 

Network Access Identifier 


■ P-CSCF 

Proxy-Call-State-Control- Function 

• 

15 

SIM (card) 

(GSM) Subscriber Identity Module (card) 


SIP 

■ 

Session Initiation Protocol 

< 

TEID 

Tunnel Endpoint ID 

• 


UE 

* • 

User Equipment 


UICC 

UMTS TC Card 

20 

UMTS 

Universal mobile telecommunication system 


URI 

Uniform Ressource Locator 


